|
![](/i/fill.gif) |
Am 02.12.2010 01:01, schrieb Jaap Frank:
> That's odd, because for me the 3.6 side is correct and the 3.7 side is
> far too bright.
Actually /that/ is odd.
> By the way, the challenge from clipka is for me a perfect gradient from
> 0,0 to 1,1 in the XY-plane. I suspect that this picture is made with
> 3.7, so that is odd again.
No, it's an image with a "visually linear" gradient created in Photoshop
while working with the sRGB color profile, which I then converted to a
custom color profile with a gamma of 1.0. The challenge is to open this
image in Photoshop and - without converting it to a different color
profile - draw a visually linear gradient over it. I don't know about
newer versions, but in Photoshop 6.0 this will have you end up with a
gradient similar to that created by POV-Ray 3.7.
> I'm reading the Gamma Stories for months now and all the same I'm confused.
> Maybe clipka can answer what is correct:
> Povray makes a calculation for a picture and the values of the first
> three pixels are 64,64,64 / 128,128,128 / 192,192,192.
> As I understand these are the values of PovRay's internal lineair color
> space.
No. POV-Ray internally works with floating point numbers.
But let's for now assume that POV-Ray happens to compute 0.25,0.25,0.25
/ 0.5,0.5,0.5 / 0.75,0.75,0.75 for those pixels.
> My questions are:
> A. What values are send to the display system at the moment of rendering:
> 1. Gamma corrected values for a 2.2. display, so not the lineair values.
Yes. In the given case that would be 136,136,136 / 186,186,186 /
224,224,224.
To be precise, the gamma may be the one specified by the Display_Gamma
INI file option, defaulting to 2.2. You can also set
"Display_Gamma=sRGB", in which case you'll get the roughly similar
adjustment specified in the sRGB color space specification ("sRGB
transfer function").
> 2. Lineair values and PovRay tells the display system to convert them to
> 2.2 display values:
No.
> B. What values are written in the png file and what is put in the gAMA
> chunk.
> 1. Same as A.1. and the gAMA chunk tells the values are gamma corrected
> for 2.2.
By default, yes. Again, you can specify the gamma using the File_Gamma
INI file option, and once again 2.2 is the default and "sRGB" is a valid
value also.
> 2. Same as A.2. and the gAMA chunk tells that the correct values should
> be 2.2 corrected values (sounds not correct, but you never can tell).
That would be the case if you set File_Gamma=1.0. But to be precise,
POV-Ray would not tell in the gAMA chunk that the values still need to
be gamma-corrected for 2.2, but rather just tell that the values are
linear, leaving it up to the image viewer to decide for which gamma to
pre-correct the data before sending them to the display.
> To complete the story:
> C.1. PovRay expects the file for a image-texture on a object to be gamma
> corrected (default 2.2) and counter corrects the values for it's lineair
> color space.
That would be the case for most low dynamic range file formats that do
not carry gamma information (or none that POV-Ray can currently
understand; e.g. BMP or JPEG).
> 2.Same, but the correction depends on the gAMA blok. With no gAMA a 2.2
> correction is used.
That would be the case for PNG images, except that an sRGB chunk would
take precedence over a gAMA chunk, and the default would be the sRGB
transfer function, which is close to (but not quite the same as) a gamma
of 2.2.
> I think that the answers are A.1 and B.1, but sometimes I begin to doubt
> that, as I read these gamma stories.
It's still true nonetheless. The original cause of confusion is
typically the impression that normally pixel values (such as displayed
by Photoshop, or by most color pickers) would be linear. They're not.
> As far as I've understood C.1 is 3.6 and C.2 is 3.7 policy.
Yes and no. In general you're right, but for PNG 3.6 already used gamma
correction if a gAMA chunk was present (it ignored sRGB chunks though,
IIRC).
Post a reply to this message
|
![](/i/fill.gif) |